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ABSTRACT 

Inspired by the access control models of social network sys¬ 
tems, Relationship-Based Access Control (ReBAC) was re¬ 
cently proposed as a general-purpose access control paradigm 
for application domains in which authorization must take 
into account the relationship between the access requestor 
and the resource owner. The healthcare domain is envi¬ 
sioned to be an archetypical application domain in which 
ReBAC is sorely needed: e.g., my patient record should be 
accessible only by my family doctor, but not by all doctors. 

In this work, we demonstrate for the first time that Re¬ 
BAC can be incorporated into a production-scale medical 
records system, OpenMRS, with backward compatibility to 
the legacy RBAC mechanism. Specifically, we extend the 
access control mechanism of OpenMRS to enforce ReBAC 
policies. Our extensions incorporate and extend advanced 
ReBAC features recently proposed by Crampton and Sell- 
wood. In addition, we designed and implemented the first 
administrative model for ReBAC. In this paper, we describe 
our ReBAC implementation, discuss the system engineer¬ 
ing lessons learnt as a result, and evaluate the experimental 
work we have undertaken. In particular, we compare the 
performance of the various authorization schemes we imple¬ 
mented, thereby demonstrating the feasibility of ReBAC. 

Categories and Subject Descriptors 

D.4.6 [Security and Protection]: Access Control 
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1. INTRODUCTION 

OpenMRS [4] is a production-scale, open-source electronic 
medical records system that has been deployed in many 
countries, including South Africa, Kenya, Rwanda, India, 
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China, United States, Pakistan, the Phillipines, etc. Despite 
its tremendous success and wide deployment, OpenMRS has 
a limitation in its access control mechanism, which is an in¬ 
stantiation of Role-Based Access Control (RBAC). This 
limitation is the topic of the following posting in the devel¬ 
oper forum [28]. 

The RBAC system provides a reasonably robust 
mechanism for restricting access to system be¬ 
haviours; however, we do not yet have a mecha¬ 
nism for restricting access to specific data (e.g., 
you can see data for patient X, but not patient 
Y; or, you can see your patient’s data except for 
specific lab results). 

An interpretation of the above limitation is that, while it 
is possible to restrict access of patient records to the role 
of doctors, it is not possible to restrict access of my pa¬ 
tient record to my family doctor. RBAC satisfies the access 
control requirements of business domains in which data ob¬ 
jects are “owned” by the organization, and thus all qualified 
personnel (i.e., of a certain role) may be granted access. 
In application domains in which privacy is a concern, the 
data objects are sometimes “owned” by individuals. There 
is now a need for finer-grained access control: e.g., my pa¬ 
tient record shall only be accessible by the clinicians who 
are actually treating me. That is, access is granted on the 
basis of how the requestors are related to me. 

The above access control challenge is one of the primary 
motivations for the recently proposed Relationship-Based 
Access Control (ReBAC) models. Originally inspired by 
the access control models of social network systems (e.g., 
Facebook), ReBAC grants access based on how the access re¬ 
quester is related to the resource owner (e.g., friends, friends- 
of-friends). This is in contrast with RBAC, in which access is 
granted by considering the attributes of the requestor. Fong 
et al. proposed a series of general-purpose ReBAC models 
[19, 21, 10], in which ReBAC is envisioned to be applied to 
application domains other than social computing, with the 
healthcare domain being an archetypical example. While 
the idea of ReBAC has undergone a number of recent ex¬ 
tensions in the literature [14, 13, 6, 16, 20, 33], what remains 
to be seen is the adoption of ReBAC in a production-scale 
system for an application domain other than social comput¬ 
ing. And this is the gap we attempt to bridge by extending 
the access control subsystem of OpenMRS to include an im¬ 
plementation of a ReBAC model. 



In this paper, we report our experience of extending the ac¬ 
cess control subsystem of OpenMRS with a ReBAC model. 
The “diff” between our extension and the original OpenMRS 
code base consists of 25,754 lines (with no context lines). 
The extension involves 113 new files, 26 new database ta¬ 
bles, and 15 web pages. Our contributions are the following. 

1. We demonstrated for the first time that ReBAC can be 
incorporated into a production-scale medical records 
system, and did so with backward compatibility to the 
legacy RBAC mechanism. 

2. We identified system engineering issues that one needs 
to address when one is to cleanly and efficiently imple¬ 
ment ReBAC in a large system (§4, §5, §6 and §10). 

3. We adapted, extended and implemented the advanced 
features of ReBAC that were recently proposed by 
Crampton and Sellwood [16]. The implemented fea¬ 
tures include a generalization of social graphs called 
authorization graphs (§5), a ReBAC analogue of roles 
called authorization principals (§7), and a Unix-style 
authorization mechanism for authorization principals 
(§8). Because OpenMRS supports a rich mechanism of 
privilege matching, the notions of authorization prin¬ 
cipals and authorization algorithms as proposed in [16] 
must be either adapted (§7) or extended (§8). Our ex¬ 
tensions involve the proposal of two semantics of au¬ 
thorization (strict-grant vs liberal-grant), as well as 
a highly efficient principal matching algorithm based 
on the idea of lazy evaluation (lazy-match). What is 
pleasantly surprising is that, even after extensive ad¬ 
justments in our implementation, the basic spirit of 
Crampton and Sellwood’s design is preserved, thereby 
demonstrating the robustness of their proposals. 

4. We designed and implemented an administrative model 
for ReBAC (§9). To the best of our knowledge, this is 
the first such implementation. 

5. We empirically evaluated the performance of the vari¬ 
ous authorization schemes in item 3 above (§10). 

2. RELATED WORK 

It has long been observed that the health domain requires an 
access control model that takes into account the relationship 
between the resource owner and the access requestor when 
an authorization decision is made [9, 29]. That was partly 
the reason that led to the proposal of an extension of Open¬ 
MRS to incorporate parameterized roles [18]. 

Relationship-Based Access Control was a term coined inde¬ 
pendently by Gates [22] and Carminati and Ferrari [11] to 
refer to a paradigm of access control in which authorization 
decisions are based on whether the resource owner and the 
access requestor are related in a certain way. Initially, Re¬ 
BAC was envisioned to be applied to the domain of social 
computing. A seminal work with this application in mind 
was that of Carminati et al. [12]. 

Fong et al. proposed a series of general-purpose ReBAC 
models [19, 21, 10], and advocated the adoption of ReBAC 
for application domains outside of social computing. The 
health domain was envisioned to be an application domain 
in which ReBAC is particularly suited. ReBAC protection 
states are social networks. Modal logic and hybrid logic were 
proposed as policy languages for specifying ReBAC policies 


[19, 21, 10]. 

In UURAC (user-to-user relationship-based access control) 
[14], a policy is specified in a regular expression-based pol¬ 
icy language. Access is granted if the resource owner and 
the access requestor are connected by a path made up of a 
sequence of edge labels satisfying the regular expression. An 
algorithm for finding a path that honors the regular expres¬ 
sion is formulated. In a subsequent work [13], the protection 
states were extended to track relationships between user and 
resources (U2R) as well as between resources and resources 
(R2R). Another innovation is the provision for multiple poli¬ 
cies to be applicable to the protection of a resource, and the 
design of conflict resolution policies (conjunctive, disjunc¬ 
tive and precedence) to arbitrate authorization decisions. 
The work proposes to employ ReBAC to regulate adminis¬ 
trative activities, but does not provide details on how that is 
achieved. The administrative actions we proposed in §9 has 
clear semantics of how they are protected by security pre¬ 
conditions, and how their executions affect the protection 
state. 

In [20], a temporal dimension is introduced into ReBAC, so 
that access control policies require entities to be related in 
a certain way in the past. The goal of this extension is to 
support the expression of social contracts in online commu¬ 
nities. In [33], ReBAC is extended to account for geo-social 
network systems, and the hybrid logic policy language is 
extended to impose relationship constraints over people lo¬ 
cated in a certain geographical neighbourhood. 

Crampton and Sellwood recently proposed a series of exten¬ 
sions to ReBAC [16]. The protection state is an authoriza¬ 
tion graph that tracks relationships among users, resources, 
as well as other abstract entities relevant to access control 
(e.g., groups, roles, etc). They also proposed a ReBAC ana¬ 
logue of roles called authorization principals. The run-time 
semantics of authorization principals are specified through 
path conditions, a language akin to regular expressions. An 
XACML-style conflict resolution mechanism was proposed 
to arbitrate authorizations when the access requestor is as¬ 
sociated with authorization principals that grant conflict¬ 
ing authorizations. A UNIX-inspired authorization proce¬ 
dure serves as a framework for binding these technologies 
together. Our implementation has adopted the ideas of au¬ 
thorization graphs, authorization principals, and the UNIX- 
style authorization procedure. Yet we employ hybrid logic 
rather than path conditions for specifying the denotation of 
authorization principals. Detailed comparison with [16] will 
be given in the rest of this paper. 

It has long been recognized that any practical access con¬ 
trol system must provide ways to modify the authorization 
state or policy [24, 30]. While administrative access control 
models, which control modifications to policies, have been 
widely studied for the protection matrix and RBAC, this is a 
relatively unexplored area in the context of ReBAC. Fong’s 
ReBAC model allows for changes to the protection state 
through the use of contexts [19], but we are not aware of 
any implementation of administrative features for ReBAC. 


3. ReBAC GOES OPEN SOURCE 



This section reviews the background materials needed for 
understanding the rest of the paper. 

3.1 An Overview of ReBAC 

In a series of papers [19, 21, 10], Fong et al. proposed a 
general-purpose access control model for Relationship-Based 
Access Control (ReBAC). This work is mainly based on the 
variant of the model discussed in [10]. 

The protection state of ReBAC is an edge-labelled, directed 
graph: directed edges represent interpersonal relationships, 
and each edge is labelled with a relation identifier to sig¬ 
nify the type of relation (e.g., patient-of). In the original 
conception of ReBAC, vertices represent users, and thus the 
protection state is a social network. (In §5, we follow the 
proposal of [16], and generalize the social network to an au¬ 
thorization graph.) 

A graph predicate determines whether particular condi¬ 
tions, relating the vertices in a graph, hold or not. We 
might, for example, define a predicate that returns true 
if two vertices are connected by an edge having a partic¬ 
ular label. More formally, a graph predicate of arity k is 
a Boolean-valued function GP{G, xi,... , Xk), where G is a 
graph that defines the current protection state of the system, 
and each Xi is a vertex in G. GP evaluates to 1 if and only 
if (xi, ..., Xk) belongs to a fc-ary relation defined over G. A 
graph predicate of arity 2 is said to be a relationship pred¬ 
icate. The relationship predicate friend-of-friend(G, * 1 , * 2 ), 
for example, returns 1 iff there exists a path of length two 
or less in G connecting xi and X2, where both edges in the 
path are labelled with the relationship type friend. 

A ReBAC policy has the form “grant access to r if RP eval¬ 
uates to 1”, where r is a resource and RP is a relationship 
predicate ]10]. An access request has the form (v,r), where 
user V wishes to access resource r. Access is permitted if 
RP{G,u,v) evaluates to 1, where u is the owner of resource 
r. (In §7, we adopt a recent idea due to Crampton and 
Sellwood ]16], and formulate ReBAC policies in terms of 
authorization principals — a ReBAC analogue of roles.) 

A graph predicate GP(G, xi,..., Xk) (with a relationship 
predicate as a special case) can be syntactically specified as 
a Hybrid Logic formula 4> [10] with k free variables.^ A local 
model checker is an algorithm that takes as input (i) a hybrid 
logic formula <j) with k free variables, (ii) a protection state 
G, and (iii) k vertices Ui, ..., Vk, and then decides whether 
the fc-ary graph predicate represented by (j> is satisfied by vi, 
..., Ufc in G. 

In the rest of this paper, knowledge of hybrid logic is not nec¬ 
essary for appreciating the contributions of this work. Nev¬ 
ertheless, examples of hybrid logic formulas will be shown 
to convey the realism of our design. Readers who are unfa¬ 
miliar with hybrid logic can safely skip those examples. 

^More specifically, a graph predicate of arity fc can be rep¬ 
resented by a hybrid logic formula (j> with fc free variables, 
such that ^ is a Boolean combination of anchored formu¬ 
las. Each anchored formula is one in which the top-level 
operator is ©a,, where x is one of the free variables. This is 
a generalization of the syntactic restriction adopted in [10] 
for relationship predicates (i.e., arity 2). 


3.2 The ReBAC Java Library 

A reusable Java library of ReBAC technologies was released 
under open-source terms [8]. The library was developed and 
maintained separately from OpenMRS. The library was also 
packaged as a Maven module for easy integration with large 
projects. 

A main feature of the ReBAC library is the implementation 
of a local model checker for the hybrid logic policy language 
of ]10]. This model checker is a cornerstone of the autho¬ 
rization mechanism in our OpenMRS extension, allowing us 
to determine membership in authorization principal (§7), as 
well as to test if an administrative action is enabled and/or 
applicable (§8). 

Recall that the inputs to a local model checker include a 
graph and the abstract syntax tree (AST) of a hybrid logic 
formula. To allow the model checker to interoperate with dif¬ 
ferent representations of graphs, we have defined an abstract 
interface for graphs. For example, in the case of OpenMRS, 
relationship edges may come from three different sources 
(§5). A concrete class that makes appropriate queries to 
check for existence of each of the three kinds of relation¬ 
ships will implement the abstract graph interface, thereby 
allowing the model checker to interoperate with OpenMRS. 

Similarly, abstract interfaces are declared for the AST nodes 
of hybrid logic formulas. This allows the model checker to 
work with different representations of hybrid logic formulas. 
One may ask why there is a need for different representa¬ 
tions of hybrid logic formulas. A motivating example comes 
from OpenMRS. In OpenMRS, all data objects are stored as 
persistent objects (via Hibernate [25]). That includes AST 
nodes of hybrid logic formulas. Consequently, there are con¬ 
crete representational demands on how AST node classes 
are declared (e.g., must be a subclass of a certain super¬ 
class). Declaring abstract interfaces for AST nodes allows 
our model checker to interoperate with such representational 
idiosyncrasies. 

Other features of the library include an XML parser for hy¬ 
brid logic formulas that are stored as XML files. 

4. ARCHITECTURE OF OpenMRS 

This section introduces the architecture of OpenMRS, and 
explains how ReBAC is built on top of this architecture. 

4.1 Interposition via AOP 

Our ReBAC implementation is based on the source code of 
OpenMRS 1.10.^ OpenMRS is built on the Spring Frame¬ 
work, which is a Java-based web application framework [32]. 
Core functionalities of OpenMRS are exposed as service- 
layer methods on the web application server. The HTML 
pages invoke the service-layer methods in order to query ap¬ 
plication data or alter application state. Access control is 
achieved by limiting access to the service-layer methods. 

Each service-layer method is annotated with either one of 
two kinds of guard.® Intuitively, a guard is a specifica- 

®The latest stable version of OpenMRS is 2.0, released on 
February 26, 2014. 

^Annotation is achieved via the Java custom annotation 



tion of privilege requirements that must be satisfied by the 
requestor in order for the invocation of the service-layer 
method to be allowed. 

1. one-of(P): Here P is a set of privileges (i.e., posi¬ 
tive permissions). The intended meaning is that the 
invoker of this method must have been granted one of 
the privileges in P in order for method invocation to 
be authorized. 

2. all-of(P): The invoker must have all of the privileges 
in P. 

Formally, we write Q \= g for a set Q of privileges and a 
guard g whenever Q satisfies g in the following sense: 

Q|=one-of(P) iff P n Q yf 0 
Q \= all-of (P) iff P 

Intuitively, if a requestor u has been “granted” a set Q of 
privileges, and Q |= g, where g is the guard of the method 
that u attempts to invoke, then invocation is authorized. (As 
we shall see in §8, there are two ways to interpret the word 
“granted”, thereby yielding two authorization semantics.) 

Spring uses aspect-oriented programming (AOP) [26] to im¬ 
plement interposition of authorization checks. The origi¬ 
nal authorization checking code is implemented as an “ad¬ 
vice” (more precisely, a “before advice”) that is “weaved” into 
the entry point of each service-layer method, thereby intro¬ 
ducing additional behaviour on method entry. Thus every 
method invocation is intercepted by the RBAC authoriza¬ 
tion mechanism. To implement ReBAC, we introduced an 
additional authorization advice. The ReBAC authorization 
advice is an “around advice”, which introduces additional 
behaviour at both the entry and exit of a method. Conse¬ 
quently every method invocation as well as method return 
is intercepted by the ReBAC authorization mechanism. 

Lesson 1. Physically localizing all authorization checks 
in an identifiable code unit (e.g., module, reference monitor, 
aspect, etc) greatly eases the extension of the authorization 
mechanism to incorporate ReBAC. 

In fact, the above lesson applies generally to all software 
systems that anticipate future evolution in their authoriza¬ 
tion mechanisms (incorporating ReBAC is but one possible 
evolution), and we have very positive experience with AOP 
in this regard. 

4.2 Combining RBAC and ReBAC 

Unmodified, OpenMRS enforces a Role-Based Access Con¬ 
trol (RBAC) model [31], although the notion of sessions is 
not implemented. That is, all roles assigned to a user are 
activated when the user logs into the system. The likely 
reason is that the notion of role activation is probably too 
exotic for medical professionals, and the extra step of role 
activation in every log-in attempt would degrade care deliv¬ 
ery efficiency. It has also been pointed out that the support 
for sessions is not essential to core RBAC implementations 
in certain application domains [27]. 

mechanism [23, §9.7]. 


As discussed above, the original RBAC authorization checks 
are implemented as an advice. We implemented ReBAC au¬ 
thorization checks as a separate advice. The configuration 
is that the RBAC authorization checks are conducted first, 
and only when access is granted by RBAC will the ReBAC 
authorization checks be conducted. In summary, access is 
granted when both the RBAC and ReBAC mechanisms au¬ 
thorize access. We have also tailored configuration files in 
such a way that system administrators who do not use the 
new ReBAC features will not observe any difference between 
the original implementation and the extended one. 

Lesson 2 (Backward Compatibility). Care must be 
taken to ensure that ReBAC features are backward compati¬ 
ble with the legacy access control model of the system. 

Crampton and Sellwood proposed a way of “encoding” RBAC 
in their extended ReBAC model [16]. This suggests an alter¬ 
native means for integrating ReBAC and RBAC: implement 
only a ReBAC model, and simulate RBAC with ReBAC. 
Such an approach would be particularly fitting if the soft¬ 
ware application is written from scratch with a requirement 
to support both access control models. 

4.3 Protection and Application State 

In an application with a traditional access control model 
(e.g., RBAC), the protection state (e.g., role hierarchy, user- 
role assignment, etc) of the system is separate from its ap¬ 
plication state (i.e., application data). This is true of the 
original architecture of OpenMRS. 

In social computing systems, however, the above is not nec¬ 
essarily true. For example, the interpersonal relationships 
articulated by users in a social network system is both appli¬ 
cation data and part of the protection state: authorization 
is granted based on the relationship between the resource 
owner and requestor. Inspired by social computing appli¬ 
cations, ReBAC inherits this overlapping of protection and 
application state. 

The above overlap is also present in the ReBAC extension of 
OpenMRS. Included in a patient record is a set of users (e.g., 
family members) related to the patient, as well as their rela¬ 
tionships. This, for example, allows clinicians to anticipate 
hereditary conditions, or to identify compatible blood, or¬ 
gan and tissue donors. These relationships obviously belong 
to the application state of OpenMRS. Yet, as we shall see 
below, ReBAC authorization checks also make use of such 
relationships when an authorization decision is computed. 
That is, these relationships constitute part of the protection 
state. 

The above overlap creates something of a dilemma. In the 
original OpenMRS architecture, patient relationships are ac¬ 
cessible only via service-layer methods, thereby ensuring 
complete mediation. Yet, the ReBAC authorization ad¬ 
vice also needs to access patient relationships. The advice 
will therefore need to invoke service-layer methods in order 
to access the relationships. As invocations of service-layer 
methods are intercepted by the authorization advice, this 
inevitably leads to an infinite loop. 



All patient data, including patient relationships, are stored 
as Hibernate persistent objects [25]. These persistent ob¬ 
jects are made accessible via Data Access Objects (DAOs). 
To break the infinite loop, we created direct access paths 
to patient relationships by configuring DAOs specihcally for 
the ReBAC authorization advice, so that the latter may ac¬ 
cess patient relationships withont mediation of authorization 
checks. The above experience leads to the articulation of the 
following general lesson for ReBAC systems. 

Lesson 3 (Application and Protection State). 
Data belonging to both the applieation and protection state 
of a system must be held in a data store which exposes two 
Application Programming Interfaces (APIs). One is medi¬ 
ated by authorization checks, the other is not. The mediated 
API is invoked by users, while the unmediated one is utilized 
internally for authorization. 

5. AUTHORIZATION GRAPH 

In the early conception of ReBAC [10], the protection state 
is a social network of users; an edge-labelled, directed graph 
in which vertices represent users and edges model their in¬ 
terpersonal relationships. Crampton and Sellwood proposed 
an extension of ReBAC in which the protection state is an 
authorization graph [16]. The vertices model not only 
users, but also resources as well as other entities that are 
relevant to access control (e.g., groups). The edges capture 
relationships among users, objects and the aforementioned 
entities. Our ReBAC adaptation of OpenMRS implements 
the idea of authorization graphs. 

When one applies ReBAC to an enterprise application do¬ 
main (i.e., a domain other than social computing), a fre¬ 
quently raised question is: Where do the relationships come 
from? This rest of this section reports our answer to this 
question, as shaped by our experience with OpenMRS. 

In OpenMRS, domain objects are all instances of the root 
class BaseOpenmrsObject, which has two subclasses 
BaseOpenmrsData and BaseOpeninrsMetadata. The instances 
of BaseOpenmrsData include users, patient records and their 
components, etc. Therefore, we take all instances of 
BaseOpenmrsData as the vertices of the authorization graph. 

The authorization graph tracks binary relationships among 
instances of BaseOpenmrsData. During our development of 
the ReBAC extensions for OpenMRS, we identified three 
categories of relationships. 

1. User-managed relationships. These are relation¬ 
ships that are explicitly articulated and managed by 
end users. An example is friendship in Facebook. 

As we mentioned in §4.3, OpenMRS enables a clinician 
to document in a patient record the relatives of the 
patient. These interpersonal relationships are consid¬ 
ered part of the authorization graph. More specifically, 
BaseOpenmrsData has a subclass Person. Recorded in¬ 
terpersonal relationships between instances of Person 
are considered to be edges in the authorization graph. 

2. System-induced relationships. The data structures 
of the system may contain relationships that are rel¬ 
evant to authorization. Examples include organiza¬ 
tional structures, object ownership, object containment 


and provenance relationships. End users are not al¬ 
lowed to directly manipulate these relationships. 

In our ReBAC adaptation of OpenMRS, we have cre¬ 
ated an extension mechanism for administrators to in¬ 
troduce new system-induced relationships. Specifically, 
a system-induced binary relation is implemented as a 
Java class that performs queries into the run-time data 
structures of OpenMRS. Such a class implements the 
ImplicitRelationIdentif ier interface, which defines 
a standard calling convention for performing relation¬ 
ship queries. At run-time, such a class will be dynami¬ 
cally loaded into the Java Virtual Machine, an instance 
of that class is created, and an appropriate method of 
that instance will be invoked when the authorization 
mechanism needs to check the system-induced relation. 
The administrator can install an extension class for 
each type of system-induced relationship. 

In our ReBAC adaptation of OpenMRS, a system- 
induced relation relates instances of BaseOpenmrsData, 
meaning that such relationships are not only among 
users, but they may also relate resources to resources, 
or persons to resources. As an example of the last 
case, we implemented resource ownership (owner) as 
a system-induced relation, relating a resource to its 
owner(s). 

3. Access control relationships. There are relation¬ 
ships that belong solely to the protection state; they 
are tracked solely for the purpose of access control, 
and have no relevance to the business logic of the 
application. Examples of access control relationships 
include role or group membership, records of access 
events (e.g., for implementing history-based policies, 
as in [20]), etc. 

In our ReBAC adaption of OpenMRS, access control 
relationships are defined among instances of the Per¬ 
son class. Manually adding or removing access-control 
edges in the authorization graph is an error-prone step. 
To reduce the cognitive burden of users, we have imple¬ 
mented an administrative model for ReBAC, thereby 
supporting a principled way for adding or removing 
access control relationships. See §9 for details. 

For example, say the family doctor of a patient may 
refer the patient to a specialist. Such a capability is 
only allowed if patient and a clinician are related by 
an access control relationship family-doctor. Once the 
referral is confirmed, the patient and the specialist will 
be related by the access control relationship referred- 
clinician, thereby enabling the specialist to access the 
patient’s record. 

Lesson 4. In a ReBAC system, relationships come from 
three sources. Some relationships belong purely to the pro¬ 
tection state (i.e., access control relationships): these are 
managed by system administrators. Other relationships are 
shared between the application state and the protection state. 
This latter kind may he further classified into (i) relation¬ 
ships that are explicitly articulated and managed by end users, 
and (a) relationships that are induced by the system data 
structure (and thus cannot be manipulated directly by users 
and administrators). 

6. ACCESS REQUESTS 



The ReBAC authorization advice needs three pieces of in¬ 
formation to compute an authorization decision: (a) the re¬ 
source r to which access is required, (b) the user u who 
wishes to have access (aka the “requestor”), and (c) the 
guard g of the service-layer method being invoked. There¬ 
fore, an access request in OpenMRS is characterized by a 
triple {r,u,g). 

The ReBAC authorization advice can discover the identity 
of the requestor (u) and the service-layer method that is 
being invoked.'* Using the Java Reflection API, the Re¬ 
BAC authorization advice can then extract the guard {g) 
of the service-layer method. The last component of the ac¬ 
cess request, namely the resource r, is not directly available. 
OpenMRS was originally designed to use RBAC for autho¬ 
rization, and that explains why the identity of the resource 
is not explicitly made available for the authorization mech¬ 
anism. In the following, we discuss how the requested re¬ 
source r is identified in a systematic manner for the ReBAC 
authorization advice. 

The ReBAC authorization advice has access to the argu¬ 
ments that are passed to the service-layer method, as well 
as the return value of that invocation. Depending on the 
kind of service-layer method, the target resource may be ei¬ 
ther (a) an argument or (b) the return value. There are two 
kinds of service layer methods in OpenMRS: 

1. A setter method is one that operates on a given re¬ 
source, which appears as one of the method arguments. 
That is, a setter produces side effects on the applica¬ 
tion state. The argument for which side effect is tar¬ 
geted is the resource that requires access control. 

2. A getter method retrieves patient information (e.g., 
searching for the records of all patients with a given 
family name). The return value of a getter method is 
either (a) a single piece of patient information, or (b) a 
collection or a map of patient information. In the for¬ 
mer case, the returned patient datum is the resource 
that requires access control, and in the latter case, ev¬ 
ery returned patient datum requires access control. 

In the original design of OpenMRS, a naming convention is 
adopted to differentiate getter and setter methods, but there 
is no way for the ReBAC authorization advice to recognize 
which argument of a setter requires access control. 

To address the above problem, we designed a custom anno¬ 
tation ©Resource for identifying (a) whether a service-layer 
method is a setter or a getter, and (b) the target resource for 
each kind. In the case of setter methods, the ©Resource an¬ 
notation can be applied to a method parameter to indicate 
that that parameter corresponds to a protected resource. 

T m{Ti Xi , ©Resource T2 X2, T3 X3) { ... } 

The ©Resource annotation is applied above to explicitly de- 

*The requestor can be identified by calling a public static 
method of the Context class in OpenMRS. The ReBAC au¬ 
thorization method is passed an argument of type Method- 
Invocation, which in turn provides access to the identity of 
the service-layer method that is being invoked. 


dare that the parameter X 2 of method m is a controlled 
resource. We systematically annotated the setter methods 
in the OpenMRS code base using the above annotation. 

When the authorization advice is invoked, it employs the 
Java Reflection API to discover if any of the parameters of 
the invoked method is annotated by ©Resource. If so, then 
it will pass the request (r, u, g) through the authorization 
procedure, where r is the value of the annotated parameter. 
Invocation of the method is only granted if authorization is 
successful. 

Similarly, the ©Resource annotation can also be applied to 
the method as a whole to declare that the method is a getter 
and thus the return value requires access control.® 

©Resource T m(.T\ xi, T2 X2, ■■■) { . . . I 

Again, we systematically annotated the getter methods in 
the OpenMRS code base using the above annotation. 

Before an invoked method returns, the ReBAC authoriza¬ 
tion advice will check if the method has the ©Resource an¬ 
notation. If so, it will perform authorization checks on the 
return value. If the return value is a single piece of patient 
information r, then the request (r, u, g) will be subject to 
the authorization procedure, and a security exception will 
be raised if authorization fails. Otherwise, the return value 
is either a collection or a map of patient information. For 
every member r in the returned collection (resp. map), the 
request (r, u, g) will be subject to authorization check. A 
collection (resp. map) containing only those rs that pass au¬ 
thorization will be returned. 

Lesson 5. The legacy authorization subsystem of some 
applications may not have direct access to both the requestor 
and the resource of an access request. A ReBAC extension 
of such applications will need to provide means for run-time 
identification of these two entities. 

1 . AUTHORIZATION PRINCIPALS 

In an early conception of ReBAC [10], a ReBAC policy has 
the form “grant access to r if RP", where r is a resource 
and RP is a relationship predicate. There are two limita¬ 
tions to this design. First, access to resource r may be per¬ 
formed via many different forms of operations, and thus finer 
grained access control based on permissions (i.e., privileges 
in OpenMRS) is desirable. Second, there is no provision of 
permission abstraction (i.e., such as roles in RBAC) to ease 
administration. To overcome these limitations, Crampton 
and Sellwood [16] proposed an extension of ReBAC that is 
based on permission granting, and invented the notion of 
authorization principals, which could be seen as a Re¬ 
BAC analogue of roles, to ease administration. In our Re¬ 
BAC extension of OpenMRS, we have adopted a variant of 

®The annotation of getter methods is not absolutely nec¬ 
essary, as the above-mentioned naming convention already 
identifies getter methods. The annotation is performed as a 
convenience for the ReBAC authorization advice. The an¬ 
notation of setter methods, however, is necessary in order 
for the ReBAC authorization advice to function properly. 



Crampton and Sellwood’s proposal. In the following, we 
will first describe the scheme that we actually implemented, 
and then discuss how it differs from the original proposal of 
Crampton and Sellwood. 

An authorization principal is defined via a principal match¬ 
ing rule of the form {AP, RP), where AP is the identiher of 
the authorization principal, and RP is a relationship pred¬ 
icate. Unlike a role in RBAC, in which membership in a 
role is defined statically (via the user-role assignment re¬ 
lation UA), the semantics of an authorization principal is 
dynamic. When a request to access resource r is issued (at 
run time), AP denotes the set of users u for which r and 
u satisfy RP, the relationship predicate that is associated 
with AP. This notion of authorization principals is actually 
familiar to us. For example, in Unix, there are three built- 
in authorization principals: “owner”, “group”, “other” (aka 
“world”); in Facebook, there are four built-in authorization 
principals: “me”, “friend”, “friend-of-friend”, “everyone”. 

Note again that, in the original conception of ReBAC [10], 
the relationship predicate in a ReBAC policy specifies a 
desired relation between the resource owner and the ac¬ 
cess requestor. In contrast, the relationship predicate in 
a principal matching rule specifies a desired relation be¬ 
tween the resource itself and the requestor. For example, 
the following principal matching rule specifies the principal 
treating-clinician. 

^treating-clinician, 

©resource(owner) ((family-doctor)requestor V 

(referred-clinician)requestor) j 

The rule says that the requestor is a treating clinician if 
she is either the family doctor or a referred specialist of the 
resource’s owner. Note that the two free variables resource 
and requestor identifies the two parameters of the relation¬ 
ship predicates. 

In our implementation, there is only one principal matching 
rule for each authorization principal AP: i.e., the princi¬ 
pal matching rule defines a functional mapping from autho¬ 
rization principals to their corresponding relationship pred¬ 
icates. We write RPap for the relationship predicate of the 
authorization principal AP. 

Permission abstraction is achieved by authorization rules of 
the form {AP,P), where AP is the identifier of an autho¬ 
rization principal, and P is a set of privileges. The meaning 
is analogous to the permission assignment relation PA in 
RBAC. That is, at run time, the members of authorization 
principal AP is granted permissions in P. 

In our implementation, there is only one authorization rule 
for each authorization principal. We write Pap for the set 
of privileges granted to authorization principal AP. 

The scheme we implemented differs from the original pro¬ 
posal of Crampton and Sellwood in the following manners. 

• Crampton and Sellwood use a formalism called path 
conditions to specify the relationship predicate RP. In 


our implementation, RP is specihed via a hybrid logic 
formula. Path conditions and hybrid logic have incom¬ 
parable expressiveness. There are certain relationship 
predicates that are expressible in hybrid logic but not 
path conditions, and vice versa. Extending our im¬ 
plementation to accommodate other specification for¬ 
malisms for relationship predicates is a modular task. 

• In Crampton and Sellwood’s proposal, an authoriza¬ 
tion rule may grant either positive or negative permis¬ 
sions (i.e., allow or deny). Complying to the origi¬ 
nal design of OpenMRS, our implementation supports 
only positive permissions. Without negative permis¬ 
sions, the conflict resolution strategies proposed in [16] 
are not needed and thus not implemented. Extension 
of our implementation to accomodate negative permis¬ 
sions and conflict resolution is a tractable endeavour. 

• An authorization rule of Crampton and Sellwood has 
an explicitly specified scope of applicability. Specifi¬ 
cally, a rule is either applicable to all resources, or it is 
applicable only to a specific resource r. Our implemen¬ 
tation supports only the hrst possibility (applicable to 
all resources). 

A number of user interface elements have been introduced 
to ease the administration of authorization principals and 
privilege assignment. First, the specification of principal 
matching rules and the specification of authorization rules 
are performed in two separate web pages. Each web page is 
protected by separate privileges. This separation of duty al¬ 
lows a different group of administrators to be responsible for 
specifying each kind of rules. Second, we have developed a 
Javascript-based structure editor for specifying Hybrid Logic 
formulas (e.g., as relationship predicates in principal match¬ 
ing rules). 

8. AUTHORIZATION MECHANISM 

Inspired by the UNIX access control model [15], Crampton 
and Sellwood proposed an authorization mechanism for de¬ 
termining when a request is to be granted. We adapted their 
proposal for OpenMRS. Given an access request {r,u,g) 
directed against a protection state (i.e., an authorization 
graph) G, an authorization principal AP is said to be en¬ 
abled iff RPAp{G,r,u) = 1. Intuitively, the requestor u is 
a member of the enabled principals for the present access 
request. Thus, requestor u is granted the privileges in Pap, 
for each enabled principal AP. Such privileges are then used 
for satisfying the privilege requirement of guard g. 

The presence of guards of the form all-of (P) present ambi¬ 
guities in the precise manner in which authorization should 
be conducted. We therefore extend the proposal of Cramp¬ 
ton and Sellwood by differentiating between two semantics 
of authorization. 

1. Liberal-grant semantics. 

• Let £ be the set of all enabled principals. 

• Let Q = Uyipgf Pap. That is, Q is the set of all 
privileges that are granted by at least one enabled 
principal. 

• Authorization is granted iff Q ]= g. 

In liberal-grant authorization, the privileges required 
by g may come from any enabled principals. The as¬ 
sumption is that the requestor u can simultaneously 



“be” all the enabled principals. 

2. Strict-grant semantics. 

• Let £ be the set of all enabled principals. 

• Authorization is granted iff there exists AP £ £ 
such that Pap \= g. 

In strict-grant authorization, the privileges required by 
g must originate from only one enabled principal. The 
idea is that the privilege requirements of g are satisfied 
only if there is an enabled principal who can “single- 
handedly” satisfy it. 

The two semantics produce identical behaviour if the guard 
g is of the form one-of (P).® They differ in behaviour only 
if the guard is of the form all-of (P) If a request is au¬ 
thorized in the strict-grant semantics then it is authorized 
in the liberal-grant semantics.® 

For each of the above semantics, we also developed two im¬ 
plementations. 

1. Eager-match strategy. This is the straightforward 
implementation of the two semantics, in which the set 
of all enabled principals is computed before an autho¬ 
rization decision is produced. 

2. Lazy-match strategy. This is an optimized imple¬ 
mentation of the two semantics. The core idea is that 
the testing of relationship predicates during principal 
matching (i.e., determining which principals are en¬ 
abled) is an expensive operation, and thus such checks 
should be avoided whenever possible. This idea is ma¬ 
terialized in two ways. First, two principals may share 
the same relationship predicate. There is no point re¬ 
evaluating the predicate for both principals. When we 
determine what principals are enabled, the same re¬ 
lationship predicate is evaluated only once. Second, 
rather than computing the set of all enabled autho¬ 
rization principals, they are computed one at a time, 
and only for the principals that are relevant. If the 
privileges associated with a principal do not contribute 
to the satisfaction of the guard in question, it is ig¬ 
nored, and its relationship predicate is not even eval¬ 
uated. Otherwise, the principal is “relevant”, and its 
relationship predicate is checked to see if the principal 
is enabled. Whenever a relevant principal is found to 
be enabled, the authorization engine checks to see if 
the required privileges are already present. If so, the 
search for enabled principals will be terminated. In 
summary, this “lazy” evaluation strategy opportunis¬ 
tically eschews unnecessary computation. The pseu¬ 
docode listings for liberal-grant and strict-grant au¬ 
thorization using the lazy-match strategy are shown 
in Algorithms 1 and 2 respectively. 


®If g = one-of (P), then P n ^ap(^s / 0 iff there 
exists AP £ £ such that P n Pap 0. That is, the two 
semantics agree in their authorization decisions. 

^Suppose g = all-of({pi,p 2 }). Suppose further £ = 
{APi,AP 2 }. Say Papi = {pi} and Pap 2 = {P 2 }- Then 
liberal grant semantics will allow access but strict grant se¬ 
mantics will deny access. 

^Suppose strict-grant allows access. There exists AP £ £ 
such that Pap \= g. In that case, V}ap&s N 9 s-® well, 
since is monotonic. Thus, liberal grant allows access also. 


Algorithm 1: Lazy-match, liberal-grant authorization of 
access request (r, m, g) against authorization graph G. 

1 let P be such that g is either all-of (P) or one-of (P); 

2 Q := 0; 

3 foreach AP do 

4 if {Pap \ Q) n P / 0 then 

5 if RPAp{G,r,u) has been evaluated then 

6 reuse previous value; 

7 else 

8 compute value; 

9 if value is true then 

10 Q := QU Pap', 

11 if Q \= g then 

12 return “allow”’, 

13 return “deny”’, 


Algorithm 2: Lazy-match, strict-grant authorization of ac¬ 
cess request (r, u, g) against authorization graph G. 

1 foreach AP do 

2 if Pap ^ g then 

3 if RPAp{G,r,u) has been evaluated then 

4 reuse previous value (which must be false); 

5 else 

6 compute value; 

7 if value is true then 

8 return “allow”; 

9 return “deny”; 


The two strategies produce the same authorization decision 
for any given access request. 

We implemented a web interface for administrators to se¬ 
lect between liberal- or strict-grant semantics, and between 
eager- or lazy-match strategy (i.e., four combinations). 

9. ADMINISTRATIVE ACTIONS 

Access control relationships in the authorization graph be¬ 
long solely to the protection state. They are not application 
data. Their existence serve only the purpose of protection. 
One way of managing such relationships will be to place the 
burden entirely on the system administrators. (In our imple¬ 
mentation, we have administrative web pages for adminis¬ 
trators to manually add or delete edges of the authorization 
graph.) This, however, is not scaleable. Imagine the task of 
adding an edge in the authorization graph to indicate that 
the family doctor of a patient is referring the patient to a 
cardiologist (and thus the said cardiologist enjoys certain 
access rights that other cardiologists do not have over the 
patient’s records). Such an action is common in the daily 
operation of a health service. It is completely impractical 
to go through the bottleneck of the system administrators 
every time such a referral is made. One way of making this 
scaleable is to delegate this operation to qualified users (e.g., 
the family doctor in the example), so that the latter may add 
this edge into the authorization graph. Yet, manual addi¬ 
tion and deletion of edges can be error prone. First, business 
logic may dictate that multiple updates to the authorization 
graph must occur together (e.g., a person may have only one 
supervisor, and thus the addition of a new supervisor edge 



must be accompanied by the deletion of an out-of-date su¬ 
pervisor edge). If the user performs one update but forgets 
another, then the integrity of the authorization graph can¬ 
not be maintained. Second, business logic may dictate that 
an update can only occur if the user performing the update 
is qualified to do so (e.g., referral can only be made by a 
family doctor). Undisciplined updates of the authorization 
graph overlooks such security requirements. 

The primary design objective of administrative actions is to 
provide a structured means for adding and removing access 
control relationships, so that such tasks can be performed 
safely by users other than system administrators. In our 
design, the declaration of an administrative action consists 
of the following components: 

• Action identifier: A unique name is used for iden¬ 
tifying the administrative action. For example, the 
referral action is identified by the identifier “Referral”. 

• Enabling precondition: Every administrative ac¬ 
tion is presumed to be performed by a user against a 
patient (e.g., a family doctor performing a referral for a 
patient). So every administrative action has two pri¬ 
mary participants, namely, the user who performs 
that action and the patient to which the action is tar¬ 
geted. The identifiers user and patient are used in the 
declaration for referring to the primary participants. 
Whether the action is enabled (see below) depends on 
whether the user and the participants satisfy a certain 
relationship predicate. Such a relationship predicate, 
called the enabling precondition, is specified as a hy¬ 
brid logic formula with free variables user and patient. 
For example, the following hybrid logic formula can be 
used for requiring that referral can only be conducted 
by the family doctor of a patient.® 

©user (fa m i ly-doctor) patient 

• Participants: Other than user and patient, there may 
be other participants involved in the action. They are 
called auxiliary participants. The participant list 
enumerates the identifiers to be used for referring to 
auxiliary participants in the rest of the declaration. 

In the example of referral, there is only one auxiliary 
participant, “specialist”, who is the specialist to which 
the referral is directed. 

• Applicability precondition: Whether the adminis¬ 
trative action is considered applicable (see below) de¬ 
pends on whether a certain condition holds among all 
the participants (both primary and auxiliary). Such 
a condition is specified as a hybrid logic formula con¬ 
taining free variables that are user, patient, as well as 
the identifiers listed in the participant list above. The 
hybrid logic formula specifies a graph predicate of arity 
£ + 2, where £ is the number of auxiliary participants. 
In the running example, we require that (a) the spe¬ 
cialist is approved by the insurance company of the 
user, and (b) the user and the specialist must belong 
to the same health region. The above conditions are 


®This is only an illustration. We are fully aware that in real 
life it is not just the family doctor who can perform referral. 


captured by the following hybrid logic formula. 

(@patient(insurance)(approves)specialist) A 

(©user (region) (—region) specialist) 

• Effects: The effects of an administrative action is a 
list of updates. Each update is of the form “add 
i{x, y)” or “del i(x, y)”. Here, i is a relation identi¬ 
fier (e.g., supervisor-of), and x and y are identifiers of 
participants (either primary or auxiliary). The key¬ 
words add and del indicates whether the update is an 
edge addition or deletion. 

For example, the referral action has one update: 
add referred-clinician(patient, specialist) 

The enabling and applicability preconditions together spec¬ 
ify the security constraints that must be met in order for 
the user to be allowed to perform the administrative action 
against the patient. The effects may involve updating mul¬ 
tiple edges in the authorization graph. Grouping them to¬ 
gether in one administrative action ensures that the updates 
are either performed together, or not at all. This in turn en¬ 
sures the integrity of the authorization graph, and prevents 
errors on the part of the user who performs the updates. 

At run time, the following sequence of events occur, which 
gives semantics to administrative actions. 

1. When a user retrieves the record of a patient, the two 
primary participants are tested against the enabling 
precondition of every declared administrative action. 
An action for which the enabling precondition is satis¬ 
fied is said to be enabled. The set of enabled actions 
is computed. 

2. When the patient record is displayed, a tab showing 
the list of all enabled actions is made available to the 
user. The user may choose to perform any of the en¬ 
abled actions. 

3. When the user signals to perform an enabled action, 
the list of auxiliary participants (if any) will be dis¬ 
played to the user. The user must now instantiate 
each of the participants by selecting a person. This 
is facilitated by intelligent search features offered by 
OpenMRS. 

4. Once the participants are selected, both the enabling 
and applicability preconditions are checked. The ac¬ 
tion is deemed applicable if the check succeeds. (We 
will explain below why the enabling precondition is 
checked again.) 

5. If the action is applicable, then the effects of the action 
will be executed. Note that deleting a non-existent 
edge is an error. Similarly, adding an edge that al¬ 
ready exists is also considered an error. Either all the 
updates are executed, or execution fails without any 
change to the authorization graph. 

Note that the execution of effects is an atomic operation: ei¬ 
ther all updates are successfully executed, or else no update 
is performed. This is achieved by the transaction manager. 
Actually, the transaction begins at step 4 above. Includ¬ 
ing the check of both enabling and application precondi¬ 
tions into the transaction prevents time-of-check-to-time-of- 
use (TOCTTOU) race conditions [7, §6.2.1]. In addition, to 
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Figure 1: The 8 experimental configurations. 


Users: | 10,000 | Privileges: | 200 

Roles: | 67 

Privilege-role assignment pairs: 

469 

User-role assignment pairs: 

50,000 


Figure 2: RBAC Parameters 


prevent unintended roll-back, the preconditions shonld be 
crafted in snch a way that the presence of an edge is verified 
in the preconditions if it is deleted in the effects, and the 
absence of an edge is confirmed in the preconditions if it is 
added in the effects. 

To support policy engineering, we also developed adminis¬ 
trative web pages for users to build a library of reusable 
hybrid logic formulas. Such formulas can be referenced in 
the declarations of administrative actions. 


10. PERFORMANCE EVALUATION 

An empirical study has been conducted to evaluate the per¬ 
formance of the various authorization schemes proposed in 
this paper. As our ReBAC-equipped version of OpenMRS is 
not yet deployed in any clinical setting, no production data 
set is available, and thus performance evaluation was con¬ 
ducted with synthetic data. Rather than performing “dis¬ 
embodied” simulation of the various authorization schemes, 
we measured the performance of those schemes within the 
infrastructure of OpenMRS, thereby capturing the overhead 
in a realistic implementation. 

We compared the performance of the OpenMRS authoriza¬ 
tion mechanism in eight different configurations (Fig. 1). 
The two RBAC configurations (Ro*) correspond to Open¬ 
MRS with only the legacy RBAC authorization mechanism 
(i.e., ReBAC is turned off). These two configurations dif¬ 
fer in whether requests are directed against one-of guards 
(RoOne) or all-of guards (RoAII). ReBAC authorization 
is turned on (and RBAC is turned off) for the remaining 
six configurations (Re*). Two of the ReBAC configura¬ 
tions correspond to one-of requests (ReOne*). They differ 
in whether eager- or lazy-match strategy is implemented. 
The last four ReBAC configurations correspond to all-of 
requests (ReAll*). In the case of all-of guards, there are 
two possible semantics (liberal- or strict-grant), as well as 
two possible matching strategies (eager or lazy), resulting in 
four configurations: ReAllEgLib, ReAllEgStr, ReAlILzLib, and 
ReAlILzStr. 

RBAC Protection State. We randomly synthesized an 
RBAC protection state for the two RBAC configurations 
(Ro*). OpenMRS pre-compiles the role hierarchy into a fiat 


space of roles. The RBAC protection state therefore con¬ 
tains a user-role assignment and a privilege-role assignment, 
but not a role hierarchy. Fig. 2 enumerates the parameters 
used for synthesizing the RBAC protection state. Justifi¬ 
cations for the choice of these parameters are given in Ap¬ 
pendix A. 

ReBAC Protection State. For the six ReBAC configu¬ 
rations (Re*), we constructed an authorization graph out 
of a social network dataset, soc-Pokec, obtained from the 
Stanford Large Network Dataset Collection [5]. The graph 
has 1.6 million nodes and 30 million directed edges. This 
dataset is thus even bigger than what the OpenMRS com¬ 
munity calls a high-density deployment.^’’ 

To construct the authorization graph, we identified 10,000 
nodes with the highest in-degrees, and labelled them as users 
(i.e., clinicians).’’ The remaining nodes are patients. Con¬ 
sequently, a directed edge in the social graph can be one of 
four types: user-user, user-patient, patient-user, or patient- 
patient. According to the type of each directed edge, we then 
randomly labelled the directed edges using the relation iden¬ 
tifiers of the Electronic Health Records System case study 
in [19, §5]. A detailed list of relation identifiers and the 
distribution of the edge labels can be found in Appendix B. 

ReBAC Policies. The six ReBAC configurations (Re*) 
presumes the existence of ReBAC policies (authorization 
principals). We generated an authorization principal for 
each of the 67 roles. Authorization rules were formulated 
in such a way that each principal grants the same privi¬ 
leges as its corresponding role. Principal matching rules 
were in place so that every authorization principal is as¬ 
sociated with a randomly generated hybrid logic formula. 
Specifically, from the two example formulas in the Electronic 
Health Records System case study in [19, §5], we extracted 
ten hybrid logic formulas for our experiment. For each prin¬ 
cipal, a formula was randomly selected from those ten for¬ 
mulas (with equal probability). See Appendix C for details. 

Methods, Guards, and Requests. As the existing service- 
layer methods of OpenMRS will not work with the autho¬ 
rization graph synthesized above, we randomly synthesized 
service-layer methods for the purpose of this experiment. 
Each synthesized service-layer method takes a patient as an 
argument, and is invoked by a user (i.e., clinician). A guard 
is randomly generated for each method; one-of guards for 
the *One* configurations, and all-of guards for the *AII* 
configurations. Each method has an empty body as we 
are only concerned about authorization overhead. For each 
of the eight configurations, we generated 200 method calls, 
with randomly selected clinicians and patients. The autho¬ 
rization times of the 200 method calls are then averaged and 
reported. Details can be found in Appendix D. 

Results and Discussions. We conducted the experiment 
on a desktop machine with AMD FX-8350 8-core Processor 


’’’According to a thread in the OpenMRS developer forum 
[1], the number of patient records in various reported Open¬ 
MRS deployments ranges from 8,982 to 741,606. 

”Our intuition is that clinicians are more connected than 
patients. Specifically, they have more incoming edges, for 
example, to indicate who is the attending clinician of whom. 






Figure 3: Average time for an authorization check 
(with 95% confidence interval). 

(16 MB cache), 16 GB RAM (1866 MHz, DDR3), and an 
840 EVO Solid State Drive running Windows 8 OS. The 
results are shown in Fig. 3. 

The baseline RBAC configurations (Ro*) incur negligible 
running time. The three eager-match configurations (*Eg*) 
have authorization time averaging around 0.33 seconds, sug¬ 
gesting that the eager-match strategy is not practical. In 
contrast, all the lazy-match conhgurations (*Lz*) have com¬ 
petitive authorization times averaging around 0.016-0.037 
seconds. In summary, matching strategy, and not autho¬ 
rization semantics, is the key determinant of performance. 

In our experience, the main performance overhead comes not 
from backtracking within the hybrid logic model checker, but 
from database accesses. Due to the sheer size of the autho¬ 
rization graph (1.6 million nodes, 30 million edges), simply 
retrieving the neighbours of a given node takes 0.002 second 
in our preliminary experiments, resulting in unacceptable 
authorization times. Noticing this, we stored the access con¬ 
trol relationships in a graph database (Neo4j [3]) instead of 
the original relational database (MySQL [2]), resulting in a 
20-fold speed-up in neighbor retrieval time (0.0001 sec) and 
thus the fast authorization times reported above (Fig. 3). 

Lesson 6 . A graph database offers more competitive Re- 
BAC authorization performance than a relational database. 

11. CONCLUSIONS AND FUTURE WORK 

This ReBAC adaptation of OpenMRS is the first implemen¬ 
tation of ReBAC in a production-scale electronic medical 
records system. We reported reusable engineering lessons 
for ReBAC deployment, presented extensions of advanced 
ReBAC features recently proposed by Crampton and Sell- 
wood [16], designed and implemented the first administra¬ 
tive model for ReBAC, and evaluated the performance of 
authorization checks. 

Our implementation can serve as a testbed for future ex¬ 
tensions of ReBAC. A number of research opportunities are 
motivated by this implementation exercise. First, the way 
ReBAC interacts with the legacy RBAC mechanism is by 
way of conjunction: access is granted if both access con¬ 
trol subsystem grant access. What are other ways in which 
RBAC and ReBAC can interact with one another to deliver 


advanced access control features? Second, authorization in 
OpenMRS is performed through the satisfaction of privilege 
requirements known as guards. These privilege requirements 
interact with the design of other access control features (e.g., 
authorization principals, authorization algorithms, positive 
and negative permissions, conflict resolution) in an intimate 
manner. We have opted for simplicity in most of our design 
choices. Further studies on how advanced access control 
features can be implemented in the presence of OpenMRS- 
style privilege requirements is a research challenge. Third, 
while we have fashioned the first administrative model for 
ReBAC, the theory of ReBAC administrative models is an 
unexplored area. How does one perform, say, safety analysis 
in this administrative model [24]? Fourth, in the original 
proposal of ReBAC [19] relationships are contextual. For 
example, a referral relationship is effective only in the con¬ 
text of a certain medical case. Context creation and removal 
provide a clean mechanism for expiration of tentative rela¬ 
tionships. How does one implement contexts in OpenMRS, 
especially with usability in mind? 
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APPENDIX 

A. RBAC PROTECTION STATE 

We create 10,000 users for our experiments. Since OpenMRS 
has 184 distinct built-in privileges, we round up and thus 
create 200 privileges. We deduce several ratios from the 
“healthcare” database of [17]: (a) role-to-privilege ratio is 
1:3; (b) average number of roles per user is 5; (c) average 
number of privilege per role is 7. From these ratios, we create 
67 roles (« 200/3), 469 privilege-role assignment pairs (« 

67 X 7), and 50,000 user-role assignment pairs (« 10000 x 5). 

B. ReBAC PROTECTION STATE 

From [19, §5], we extract the following relation identifiers. 

We indicate below the type of each identifier: e.g., an iden¬ 
tifier of the patient-user type is identified by “p-u”. 


Rel. Id. 

Type 

Rel. Id. 

Type 

gP 

referrer 

appoint-team 

team 

P-U 

u-u 

u-u 

u-u 

register-ward 
ward-nurse 
agent 

p-u 

u-u 

p-p 


Every directed edge in the social graph belongs to one of 
the four types: user-user, user-patient, patient-user, patient- 
patient. Based on the type of a given directed edge, a rela¬ 
tion identifier of that type is random selected (with uniform 
distribution). Note that there is no relation identifier that 




has the type user-patient. For those edges, a dummy rela¬ 
tion identifier is assigned. 

C. ReBAC POLICIES 

The Electronic Health Records System case study of [19, 
§5] has two formulas that we can use in our experiments. 
The first formula, specifying the patient-clinician relation, 
is constructed incrementally in four stages in [19, §5.1]. We 
take the subformulas constructed in the various stages as 
candidate formulas for our experiment. 


4>i 

4>2 

4>3 

4>i 

4‘5 


4>6 

4>7 

4>s 

09 


(gp) requestor 

(gp) {— referrer) requestor 

01 V 02 

{gp){—referrer)(appoint-team) requestor 
{gp)(—referrer)(appoint-team)(requestor V 
(member) requestor) 


03 V 05 

(register-wa rd) requestor 
(register-ward)(requestor V 

(ward-nurse) requestor) 

06 V 08 


The last candidate formula is basically a minor adaptation 
of the formula expressing the agency relation in [19, §5.2[. 

010 = (gp)requestor V (—agent)(gp)requestor 

D. AUTHORIZATION REQUESTS 

We generated 400 methods with all-of guards, and another 
400 with one-of guards. The set P of privileges for each 
guard contains a minimum of one and a maximum of three 
privileges randomly selected from the 200 available privileges 
(Fig. 2).^^ In addition to the privileges we randomly gener¬ 
ated a list of 400 clinician, and a list of 400 participants, to 
serve as participants in the authorization requests. 

The methods were invoked in order (from 1 to 400) along 
with the corresponding clinician, patient pair. This pro¬ 
cess was uniformly conducted for all configurations, with the 
*One* configurations invoking the methods with the one-of 
guards, and the *AII* configurations invoking the methods 
with the all-of guards. The first 200 method invocations 
were discarded as they were used for warming up the Java 
Virtual Machine. The performance of the remaining 200 
method invocations were recorded. 

E. Neo4j WARMUP 

Retrieving the neighbourhood in Neo4J normally start out 
slow then speeds up, and stabilize at an average of 0.0001 
seconds after approximately 250 queries. Therefore, we ran¬ 
domly generated 250 distinct neighbourhood retrieval queries 
that were ran before the method invocations for each test 
configuration. 


^^The service-layer methods of OpenMRS never have a priv¬ 
ilege set of size larger three. 



